home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 2 / Atari Mega Archive CD - Volume 2.iso / 8bit / cislib_a / bugs4.act < prev    next >
Text File  |  1995-04-22  |  9KB  |  327 lines
  1.     ACTION! BUG SHEET #3 - part 4
  2.  
  3. -------------------------------------
  4.  
  5.           PROBLEMS WITH PAD
  6.  
  7. We will list the problems (and
  8. solutions) regarding the Programmer's
  9. Aid Disk here in reasonably compact
  10. form.
  11.  
  12. 1.  BGET/BPUT PROBLEMS -- The BGet
  13.     and BPut routines in the IO.ACT
  14.     file do not work properly under
  15.     certain conditions.  To fix this
  16.     bug, replace the BGet and BPut
  17.     routines with the following
  18.     ACTION! code:
  19.  
  20.     ;********************************
  21.     ;Burst (Block) I/O routines to do
  22.     ;quick disk I/O, utilizing a call
  23.     ; to CIO
  24.     ;********************************
  25.  
  26.     PROC CIO=$E456( BYTE areg, xreg )
  27.  
  28.     ;********************************
  29.  
  30.     CARD FUNC Burst( BYTE chan, mode,
  31.                 CARD addr, buflen )
  32.  
  33.       TYPE IOCB=[BYTE id,num,cmd,stat
  34.                  CARD badr,padr,blen
  35.                  BYTE a1,a2,a3,
  36.                       a4,a5,a6]
  37.  
  38.       IOCB POINTER iptr
  39.  
  40.       chan ==& $07
  41.       iptr = $340+(chan LSH 4)
  42.       iptr.cmd  = mode
  43.       iptr.blen = buflen
  44.       iptr.badr = addr
  45.       CIO( 0, chan LSH 4 )
  46.     RETURN( iptr.blen )
  47.  
  48.     ;********************************
  49.  
  50.     CARD FUNC BGet( BYTE chan,
  51.                     CARD addr, len )
  52.       CARD temp
  53.  
  54.       temp = Burst(chan,7,addr,len)
  55.     RETURN( temp )
  56.  
  57.     ;********************************
  58.  
  59.     PROC BPut(BYTE chan,
  60.               CARD addr,len)
  61.       Burst( chan, 11, addr, len )
  62.     RETURN
  63.  
  64. 2.  PRINTF -- The PRINTF routine has
  65.     a bug which was reported and
  66.     fixed in the Spring, 1984
  67.     newsletter.  In the file
  68.     PRINTF.ACT, use the ACTION!
  69.     editor to find
  70.        args ==+ s
  71.     and change it to
  72.        args ==+ 2
  73.  
  74. 3.  PLAYER/MISSILE GRAPHICS --
  75.     Because S: uses some memory just
  76.     below the display list
  77.     (undocumented), our method of
  78.     finding the base address for
  79.     Player/Missile Graphics needs a
  80.     slight revision.  Use the ACTION!
  81.     editor with the file PMG.ACT to
  82.     find
  83.       PM_BaseAdr=(HiMem-
  84.             PM_MemSize(mode))
  85.             &PM_AdrMask(mode)
  86.     and change it to
  87.       PM_BaseAdr=(HiMem-
  88.             PM_MemSize(mode)-$80)
  89.             &PM_AdrMask(mode)
  90.  
  91. 4.  If you use the PMMove procedure
  92.     and specify a vertical movement
  93.     of zero, the horizontal movement
  94.     does not take place (it should).
  95.     To fix this, change the lines in
  96.     PMG.ACT which read
  97.        IF deltay=0 THEN
  98.          RETURN ; do nothing
  99.        FI
  100.     to the following:
  101.        IF deltay=0 THEN
  102.          ; do horizontal anyway
  103.          PMHpos(n)=x
  104.          RETURN
  105.        FI
  106.  
  107. 5.  PLAYER/MISSILE GRAPHICS -- The
  108.     documentation for PMG.ACT states
  109.     that you may read the contents of
  110.     PMHpos to find the horizontal
  111.     position of a player or missile.
  112.     This is simply not true.  PMHpos
  113.     is a set of write-only hardware
  114.     registers.  (Note that in the
  115.     ToolKit we have added a shadow
  116.     array and changed the name of the
  117.     hardware registers, so this works
  118.     correctly.  If you wish, you
  119.     could consider doing something
  120.     similar on your PAD.)
  121.  
  122. 6.  REAL NUMBER ROUTINES -- There are
  123.     two discrepancies in PROCedure
  124.     names in the REAL.ACT library as
  125.     compared to the REAL.DOC
  126.     documentation, as follow:
  127.       Name in .DOC     Name in .ACT
  128.         StrR             RealToStr
  129.         ValR             StrToReal
  130.     We suggest that you change the
  131.     source code in REAL.ACT to
  132.     reflect the names given in the
  133.     documentation (rather than vice
  134.     versa), since this makes the
  135.     names appear compatibile with the
  136.     library's other number-string
  137.     conversion routines.
  138.  
  139. 7.  REAL NUMBER ROUTINES -- In that
  140.     same area, the routine RealToStr
  141.     (or should that be StrR?) needs
  142.     to change the line which reads
  143.        ptr=LBuff
  144.     to the following:
  145.        ptr=InBuff
  146.  
  147. 8.  ALLOC.ACT -- The free list
  148.     pointer may not be set up
  149.     properly.  Also, when freeing a
  150.     block, right adjacency is not
  151.     handled properly if left
  152.     adjacency has already been found.
  153.     Fix these problems as follows:
  154.  
  155.     In the PROCedure Free, after the
  156.     line reading:
  157.        last.size==+nBytes
  158.     insert the line:
  159.        target=last
  160.  
  161.     Also, in the same procedure,
  162.     change the line reading:
  163.       IF target+nBytes=current THEN
  164.     to read:
  165.       IF target+target.size
  166.             =current THEN
  167.  
  168.     In the PROCedure AllocInit,
  169.     replace the line reading:
  170.       FreeList.next=p
  171.     with the following lines:
  172.       FreeList=p
  173.       p==+4
  174.       FreeList.next=p
  175.  
  176. -------------------------------------
  177.  
  178.           TOOLKIT TROUBLES
  179.  
  180. It's hard to believe that a product
  181. as new as the ACTION! ToolKit can
  182. already have bug reports.  Sigh.
  183. Anyway, there are already three
  184. versions of the ToolKit.  Version 1
  185. has 31 free sectors (when you list
  186. its directory).  Version 2 has fewer
  187. free sectors and the second line of
  188. the file MUSIC.DEM reads ";Version
  189. 2".  On version 3, the file ABS.ACT
  190. starts with the version number.  This
  191. last convention will be followed in
  192. future versions.  The comments here
  193. are organized by affected version(s).
  194.  
  195. VERSION 1 ONLY
  196.  
  197. 1.  I/O ROUTINES -- The manual
  198.     describes a routine called Format
  199.     (in the IO.ACT library), but no
  200.     such procedure exists on the
  201.     disk.  However, the routine is
  202.     there--it's just called Init
  203.     instead.  You should change your
  204.     disk to match your manual.
  205.  
  206. 2.  MUSIC.DEM -- The program called
  207.     MUSIC.DEM will not work as is on
  208.     older 400/800 machines.  This is
  209.     because it uses a call to
  210.     Graphics(15), which is only
  211.     available on XL machines.  You
  212.     may change the program to use
  213.     Graphics(8) with no effect except
  214.     that the true colors of mode 15
  215.     become artifact colors in mode 8
  216.     instead.
  217.  
  218. VERSIONS 1 AND 2
  219.  
  220. 1.  REAL ROUTINES -- There are two
  221.     discrepancies in PROCedure names
  222.     in the REAL.ACT library as
  223.     compared to the REAL.DOC
  224.     documentation, as follow:
  225.  
  226.       Name in .DOC     Name in .ACT
  227.          StrR            RealToStr
  228.          ValR            StrToReal
  229.  
  230.     We suggest that you change the
  231.     source code in REAL.ACT to
  232.     reflect the names given in the
  233.     documentation (rather than vice
  234.     versa), since this makes the
  235.     names appear compatibile with the
  236.     library's other number-string
  237.     conversion routines.
  238.  
  239. 2.  SORT ROUTINES -- There are four
  240.     discrepancies in PROCecure names
  241.     in the SORT.ACT library as
  242.     compared to the SORT.ACT
  243.     documentation, as follows:
  244.  
  245.        Name in .DOC    Name in .ACT
  246.           SortB           BSort
  247.           SortC           CSort
  248.           SortI           ISort
  249.           SortS           SSort
  250.  
  251.     Please change your disk file to
  252.     agree with your manual.
  253.  
  254. 3.  PRINTF -- The PRINTF routine has
  255.     a bug which was reported and
  256.     fixed in the Sprint, 1984
  257.     newsletter.  In the file
  258.     PRINTF.ACT, use the ACTION!
  259.     editor to find
  260.        args ==+ s
  261.     and change it to
  262.        args ==+ 2
  263.  
  264. VERSIONS 1, 2, AND 3.
  265.  
  266. 1.  ALLOC ROUTINES -- The manual in-
  267.     dicates that the procedure
  268.     AllocInit requires that you pass
  269.     it the address of the first free
  270.     byte of memory (because Alloc
  271.     "dispenses" memory from the first
  272.     free byte through the top of
  273.     memory, as correctly described in
  274.     the manual).  However, since you
  275.     MUST follow the procedure
  276.     described in the introduction to
  277.     ALLOCATE.ACT (that is, you must
  278.     declare in your program a CARD
  279.     called EndProg and use the
  280.     command
  281.        SET EndProg=*
  282.     after compiling), the parameter
  283.     to AllocInit is not really needed
  284.     and so has been eliminated.
  285.     (AllocInit uses EndProg just as
  286.     Alloc does.)  If you pass a
  287.     parameter to AllocInit, it will
  288.     be ignored.
  289.  
  290. 2.  WARP.DEM -- No mention is made in
  291.     the Toolkit manual that this file
  292.     can only be run when compiled
  293.     from disk (unless you are using
  294.     DOS XL to gain extra memory).
  295.     WARP.DEM is just too big for
  296.     ACTION! to hold both the source
  297.     and object in memory at one time.
  298.  
  299. 3.  ALLOCATE.ACT -- The free list
  300.     pointer may not be set up
  301.     properly.  Also, when freeing a
  302.     block, right adjacency is not
  303.     handled properly if left
  304.     adjacency has already been found.
  305.     Fix these problems as follows:
  306.  
  307.     In the PROCedure F